1. Field of the Invention
The present invention relates generally to the field of accelerating communications across a network, and in particular accelerating one or more Transmission Control Protocol (TCP) communication sessions across a network, for example across a satellite communication network.
2. Discussion of the Background
TCP attempts to provide a reliable communications channel over an unreliable network by arranging for packets to arrive intact and in order at their proper destination. TCP uses a sliding window system allowing up to 65535 bytes to be outstanding at any given time. To avoid over-saturating the network, TCP also implements algorithms such as congestion avoidance and slow start. Features of TCP are further described in Stevens, W. Richard, TCP/IP Illustrated Volume 1: The Protocols, Addison-Wesley, Massachusetts, 1994, which is hereby incorporated herein by reference in its entirety.
The TCP protocol does not readily support channels with high latency or high loss. TCP interprets the absence of timely acknowledgements as congestion and under these conditions, TCP reduces its transmission speed and window sizes. In the case of high latency, even with a lossless channel, TCP allows a maximum of 65535 bytes to be sent before an acknowledgement is received, which may not be adequate for a high bandwidth satellite link, for example a geosynchronous satellite link.
Conventional network communication systems may be configured to rely on endpoint configurations to overcome satellite link delay and loss, such as using SACK, as described in “TCP Selective Acknowledgment Options,” October 1996, IETF RFC-2018, incorporated herein by reference in its entirety, or TCP window compression, as described in “TCP Extensions for High Performance,” May 1992, IETF RFC-1323, incorporated herein by reference in its entirety. However, conventional schemes may require a complex or unique configuration for each communication node, and also may still result in delayed or lossy communications.
Other conventional communication systems having a relatively fast communication segment with a high latency and/or low loss (e.g., a wired connection) in series with a relatively slow communication segment having low latency and/or low reliability (e.g., a satellite link) may include a method of TCP acceleration to improve communication reliability and to allow client computers that communicate through the slow segment to use normal TCP protocol (i.e., without repeated unnecessary retransmission of packets). However, conventional TCP acceleration systems may not efficiently manage computing resources, such as processor execution cycles, memory, disk space, and channel throughput, etc. . . .
For example, the bandwidth of a link, multiplied by the round trip time over that link is known as the link's Bandwidth Delay Product (BDP). For example, a 5 megabit/sec (Mb/s) satellite link with a latency of 500 milliseconds (ms) has a bandwidth delay product of 312,500 bytes. Thus, in a conventional method 312,500 bytes would have to be sent without waiting for an acknowledgement in order to fully utilize the link. However, 312,500 bytes is greater than the number of bytes that may be sent before receiving an acknowledgment according to the requirements of TCP.
Another issue that may arise in the presence of high latency is slow start. TCP has a slow start algorithm that may increase transmission speed once every round trip. When the round trips take a long time, it can take a significant amount of time to get past the slow start algorithm. If packets are lost and the TCP session slows down, the slow start phase will have to be overcome again, resulting in further delays.
Further, events may occur that result in significant and rapid increase of system resources demanded by a particular TCP session or by an application that shares resources with the TCP acceleration system. For example, during a software upgrade to plural users, significant resources may be required by a communication application to transfer files. Conventional TCP acceleration methods may be unable to efficiently react to this change in required resources. When data has been accelerated over a satellite link, for example, but is not being received by the remote client, a full BDP worth of data may be queued. If this situation occurs in even a small number of sessions, system memory may be quickly exhausted when the BDP is high.
Further, TCP sessions involve numerous states and timers which consume CPU cycles, and there are a finite number of TCP sessions, which can be simultaneously handled. In addition, there may be a relatively high latency link between two acceleration layers, so bandwidth may be wasted on traffic that has no hope of arriving at its destination.
Further, increased “virtual throughput” due to TCP acceleration may require an increased use of memory. However, background TCP acceleration methods may disadvantageously allocate too much memory to a TCP session.
Further, background TCP acceleration methods may transmit uncompressed packets regardless of CPU utilization, thereby resulting in disadvantageously high usage of valuable communication resources.
Further, packets transmitted from a first client to a first acceleration layer using a conventional acceleration method may disadvantageously be received out of sequence at the first acceleration layer. A conventional first acceleration layer may retransmit packets in the order they are received. Thus, when they arrive at the second acceleration layer out of sequence, an inefficient retransmission across the slow segment is required to correct the packet sequence.
Further, some clients/TCP stacks do not open their window size as large as they advertise (i.e., the MSS or maximum segment size of a client). Thus, a background TCP acceleration scheme may never send a particular packet (or might disadvantageously delay the transmission of a packet) if the packet is sized according to the reported window size of that client.
Further, conventional acceleration methods may not ensure fairness across TCP sessions within a given service level (e.g., a Quality of Service, a desired rate, a desired latency, etc. . . . ). That is, in a conventional method, a first TCP session may be allocated more communication resources than a second TCP session, even if they are operating at the same service level. Further, in the conventional acceleration methods a user having a large amount of data to transmit may disadvantageously slow or starve a different user having a smaller amount of data to transmit.
FIG. 10 shows an example of a conventional TCP communication system without TCP acceleration. In this example, client A 100 communicates with client B 112 using communication segment 114. FIG. 11 shows an example of a conventional TCP session between clients A and B of FIG. 10. Client B initiates the session by sending a packet having the synchronize bit (i.e., SYN bit) set in the header SYN 1100 to client A, which replies with SYN ACK 1102. Client B responds with ACK 1104 and sends data packets 1106 and 1108 to client A. Client A replies with ACK 1110 and client B initiates conclusion of the TCP session by sending a packet having the finish bit (i.e., FIN bit) set in the header FIN 1112 to client A, which sends ACK 1114 and FIN 1116 to conclude the TCP session.